|
|
|
|
|
|
|
Use Cases and the Jacobson Methodology |
|
|
|
|
|
|
|
|
When Microsoft released version 5 of Visual Basic Enterprise, the Visual Basic language moved into the ballpark of object-oriented languages (although only as a pinch hitter perhaps, but close enough). The capability to create classes whose interfaces can be implemented by other classes and the capability to create complex ActiveX components have made Visual Basic a serious commercial development tool. Added to that is the automation of the design process with the help of Microsoft Visual Modeler. However, Visual Basic doesn't help with the discovery and identification of classes, actors (human and external system), and use cases. To compound this situation, most Visual Basic programmers don't have an object-oriented background, which leaves the programmers resorting to traditional, familiar ways of developing software. |
|
|
|
|
|
|
|
|
In reality, solid system architectures and class structures never evolve or mature properly when programmers don't know how to discover use cases and classesit's like pouring new wine into old wineskin bottles. As a result, Visual Basic, which is a strong development tool for implementing object technology, will continue to be maligned. The remainder of this chapter explains how to use object-oriented analysis techniquesspecifically use case identification and modelingto help you successfully initiate the analysis process and give Visual Basic a better name in the development community. |
|
|
|
|
|
|
|
|
Figure 2.1, earlier in the chapter, illustrates a simple use case model. Of course, the elements within a use case model don't appear out of thin air. As an analyst, you ask the user, In what ways do you want to use the system? The user, who is a teller within your development context, responds that she wants to be able to open an account, close an account, deposit new funds, and withdraw funds. Because the teller uses the system, that teller is an actor in your system. Notice how each phrase includes an important verb, such as open, close, deposit, and withdraw. These verb phrases, taken together with the actor performing these verbs, provide the context for your system. When formally written down, these phrases become the core verbiage in what's called the problem statement. In other words, a problem statement provides the formal boundaries (or context) for the foundation of your Visual Basic application. Figure 2.3 illustrates a problem statement. |
|
|
|
|
|
|
|
|
When the problem statement has matured over one or more sessions with domain experts (users who are knowledgeable about a particular area of concern), you'll want to peruse this document to identify key nouns and verbs. The list of nouns becomes a list of candidate actors or classes, whereas the list of verbs provides a candidate list of business processes carried out by actors. (Keep in mind that actors are human users of your system or external systems that interact with your system.) These verbs can also indicate |
|
|
|
|
|